Preventing New Views

Hi all,

One of the problems we have with DOORS users is that they can add new views to a module.  Although this is handy, what invariably happens is the person gets a new job or leaves the company and then we have all these extra views cluttering up the module.  Additionally, people will start with another view, modify it and save it, and not realizing the access prevents them from modifying it or deleting it.  This becomes a maintenance nightmare, uses up resources and affects performance.

I was thinking if there would be a way to either prevent non-administrative people from saving views, or at the least, adding in the admin group to the access to be able to modify/delete.  Maybe a trigger in dxl that would trigger off when someone is trying to save a view that would do either of these items before the view is saved.

Has anyone done anything like this?  Any other suggestions?

Thanks for the help,

Greg

Re: Preventing New Views
Mathias Mamsch - Fri Dec 13 12:07:44 EST 2013

Well normally for the stuff that you cannot trigger on (like view creation), you have (at least) two possibilities:

• make a batch job that is scheduled to run periodically that will delete / grant access to all items
• deploy a modified DOORS client, that will prevent the user from creating stuff in the first place. Note that you cannot easily prevent them from doing stuff in DXL.

Regards, Mathias

Re: Preventing New Views
GregM_dxler - Mon Dec 16 09:36:18 EST 2013

Thanks for the input Mathias,

Not what I wanted to hear, but definitely good information to know.  The batch job is probably the way to attack this problem for now. 

Yup, I understand you can't prevent as much in dxl.  Luckily most of the users don't want to learn dxl.

Thanks again for the input.  I appreciate it.

Greg

Re: Preventing New Views
llandale - Mon Dec 16 14:36:17 EST 2013

I insist users put their user names as the first word of their views. 

yes, "batch" as the "Administrator" could add database and project admin groups to all view accesses.

You could also have two batcjhes, one adds user "DeleteMe" to all the view acesses, and another that deletes all view with that user.  Run the 1st at the start of each month and the 2nd at the end; advertise that users need to remove that user from all their custom views.  Thus, old views folks don't care enough about to maintain get deleted.

-Louie

Re: Preventing New Views
Adamarla - Tue Dec 17 03:56:22 EST 2013

Another way is to use a close module trigger to add permissions to views/delete them.

Wont wok if a user kills doors before closing the module, but they would have to do that every time to always prevent the trigger running.

-Adam

Re: Preventing New Views
llandale - Tue Dec 17 16:17:50 EST 2013

Mmmmmm.  Let me think outloud..

• pre-close-module trigger
• set(trigPreConPass) always
• Do nothing if module  not visible
• for each view..
  • If already Specific then insure DB Admins and Proj Admins have full RMCDA access
  • if view is not "project approved" and the first word of view doesn't look like a User name, then add the current user's name to the name of the view.  I wonder if Project Approved means in the template module.

I'm thinking all this view loading when closing a module may become very tiresome for users very quickly; expecially if some view had intense Layout or Attr-DXL.

-Louie

Re: Preventing New Views
Adamarla - Wed Dec 18 03:40:34 EST 2013

No need to load them unless you actually want to check the columns/filter etc in the view.

You can modify/add/remove permissions and rename without loading.

I add an admin group and prefix user initials to the name of new views. Initials are good enough indication of owner without taking too much space. Can always check the permissions for the actual username.

-Adam

Re: Preventing New Views
GregM_dxler - Wed Dec 18 08:53:14 EST 2013

Hi all,
Great info.  I think for the start, I would just want to make sure the admin group has access.  Renaming to add initials would be good, but I can see users screaming that they can't find the view they made the next time they try to use it, without realizing it has just simply been renamed.

Thanks for the help,

Greg

Re: Preventing New Views
llandale - Wed Dec 18 10:16:12 EST 2013

As for views...  Don't have much experience with views; didn't realize you didn't need to "load" it.

You are saying I get the view handle but do not "load" it, something like this:

• for NameView in views(mod) do
• {  v = view(item(fullName(mod)), NameView)
•    specific(v)
•    set(v, RMCDA, NameGroup_Admin_DB)
•    set(v, RMCDA, NameGroup_Admin_MyProj)
• }
• // no need to "save(v)" since there is no "load".

And ... noticing that you get a "View" handle from an "Item", I notice we can adjust the accesses of a view without actually opening the module.

• Item itm = item("MyModule")
• View v = view(itm, "Desired Level View")
• print (null v) "\t" (name(v)) "\n"
• inherited(v)
• specific(v)
• //save(v)   .. fails

So I'm presuming you need to "load" and "save" a view only for the "Advanced" settings, and the module must be open.  I'm presuming you do not need to open mod nor load/save for General and Access info of the view.

I notice however you cannot loop through existing views without the module being open; so adjusting basic view settings for non-opened modules would be done only with views known to be supposed to be in the module; "standard project views".

-Louie

Re: Preventing New Views
llandale - Wed Dec 18 10:28:25 EST 2013

Some DB admins (not mentioning Tony by name) would approve of folks "screaming" who don't follow reasonable policies.  Actually, I think he would go ahead and just delete poorly formed views: they are more likely to follow policies later if you make them howl now.  I have to admit that approach is effective, easier to implement, and has considerable personal emotional appeal.

Other admins may be willing to display a dialog box informing them of the rename.   Forcing them to deal with the ack will be annoying to them enough.

Guess your choice of Admin style would be whether you are after either "compliance" or "cooperation".

-Louie

Re: Preventing New Views
Adamarla - Wed Dec 18 10:53:17 EST 2013

Yep, that is what I'm saying.

You can also change more view settings with the ViewDef. Example:

ViewDef oViewDef = get(oView)
useWindows(oViewDef, false)
change(oView, oViewDef)

I do that too, so public views don't cause the module to jump around the screen when switched to.

-Adam

Re: Preventing New Views
llandale - Wed Dec 18 11:32:02 EST 2013

ViewDef oViewDef = get(oView)
useWindows(oViewDef, false)
change(oView, oViewDef)

Yes, saving window position and size is a relative disaster ..err.. particularly annoying, especially when the folks saving it put the module window on their 2nd monitor or make it fit full screen.

I get the feeling this "View" and "ViewDef" stuff is another one of those black holes for me; as perhaps some folks recall Reqexp were some years ago.  Sure seems to be taking a long time for me to get "over the hump" on this one.

-Louie

Oh and yes.  Need to be the "Administrator" when dealing with views since by default, nobody but the creater can even see it.

Re: Preventing New Views
Adamarla - Wed Dec 18 12:52:22 EST 2013

Administrator user is not necessary if you go with triggers, as they will run with the users permissions and can therefore 'see' their private views.

-Adam